Databases and information systems comprise a large part of modern infrastructure. A database is a structured collection of records or data that is stored in a computer to answer a query. The query may come from a user of the computer, another computer, or a program. The information in the database can be utilized to make a decision. The database can be configured to store any type of information.
In a personal or business environment data is a valuable and important commodity. As such, it is important to protect data from being lost or corrupted. In particular, it is important to quickly recover data from a database into a working state after the failure of a computer. In a typical environment, information in a database is copied and stored on a persistent backup media. The database, in turn, can be recovered from the backup media after a failure.
While in some environments a database can be recovered while a computer is offline, in many high performance and high availability applications, database recovery is required to occur while a computer is online and in an operational state. Otherwise, the database recovery process could render the computer unavailable an unacceptable amount of time. Recovering a database while a computer is operational, however, can introduce significant complexities and difficulties due to the need to coordinate the recovery of database information with ongoing attempts to access information in the database.
Recovering a database may involve restoring logical objects, based-on objects, ordering sensitivities (i.e. some databases, objects, files, libraries, and indices may be required to be restored before others), and rebuild indices. Typically, an object, library, or index cannot be accessed by the user before it has been restored. Recovering a database involves the need for an operator or administrator to help recover the database, the need to re-spin backup media such as a tape drive one or more times, and the need to rebuild database indexes.
In a typical database, several dependency and ordering sensitivities may exist. There may be multiple indexes, multiple libraries, and multiple objects with several dependencies in other databases, objects, libraries, or indexes. Consequently, when restoring multiple libraries, the user may have difficulties managing logical files or Structured Query Language (“SQL”) views that reside in a different library than their own based-on or physical file. If a library with a logical file is restored before a library with an underlying physical file (or based-on file), the logical file will not restore. A database recovery process normally requires the user to monitor a joblog for restoration failures. Alternately, a database recovery process will query another file, called an “outfile,” to detect such failures. A notification will go to the outfile each time there is a dependency that has not been resolved. To restore a single logical file successfully, it may be necessary to re-spin tape media (i.e., rewind the tape and perform another restore using the same media) several times to restore based-on files first. This problem is compounded when there are many logical files with other based-on logical files.
A SQL Materialized Query Table (“MQT”), also called a summary table, has the same problem with restoration as the SQL views and logical files described above. MQTs are physical files, but like SQL views, they may have dependencies on one or more based-on files. Therefore, an MQT cannot be restored if a based-on file is missing.
Database indexes have the same problems as other logical files. However, restoring a database index can be a Catch-22. An index cannot be restored if an underlying based-on file is missing. Conversely, if a based-on file is restored first, the index must be rebuilt. Rebuilding database indexes can be extremely time consuming, oftentimes adding hours to the time required to recover a database. To avoid rebuilding an index it is necessary that the index be restored along with the based-on files. When restoring networks of files that span libraries the user has no control over this problem and may only avoid the problem entirely by creating indexes in the same library as the based-on files. This is a very restrictive design consideration and may not be an acceptable circumvention to certain database users.
Consequently, there is a need to improve restoration of a database that has data with one or more dependencies.